Администраторы VMware vSphere знают, что для виртуальных машин, работающих на серверах VMware ESXi, есть операция Suspend, которая позволяет поставить виртуальную машину "на паузу", что означает сохранение памяти ВМ на диск. Когда машину потребуется "продолжить" (Resume), ее память с диска будет загружена в физическую RAM и она продолжит исполнять инструкции.
В платформе Microsoft Hyper-V есть такая операция Save, которая работает аналогично операции Suspend в ESXi, однако есть и операция Pause, которая работает несколько иначе: виртуальная машина прекращает исполнять инструкции, но память ее продолжает оставаться загруженной в оперативную память сервера. Вследствие этого, такая ВМ может быть быстро продолжена, так как не требуется загружать память с диска.
Есть ли такая операция в VMware vSphere? Как пишет Вильям Лам, оказывается, есть. Для этого можно поступить с VMX-процессом виртуальной машины так же, как и с любым другим процессом в случае его "замораживания" в Unix-системе.
Итак, чтобы поставить ВМ на такую "паузу", идентифицируем ее PID (Process ID). Для этого выполним команду:
# esxcli vm process list
PID виртуальной машины приведен в секции "VMX Cartel ID" результатов вывода команды:
В качестве альтернативы можно использовать также команду ps:
# ps -c | grep -v grep | grep [vmname]
Ну и, собственно, ставим ВМ на паузу:
# kill -STOP [pid]
Чтобы снять машину с паузы, выполняем команду для продолжения VMX-процесса:
# kill -CONT [pid]
Машинка продолжит возвращать пинги:
Надо отметить, что эта штука не работает с виртуальными машинами, для которых включена функция VM monitoring, поскольку этот механизм ничего не знает о такой возможности по приостановке виртуальных машин.
Ну и, само собой, несмотря на то, что эта штука вполне себе работает, она не поддерживается со стороны VMware.
На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.
DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).
Появилась эта утилита по той причине, что пользователи VMware vSphere не знали, что происходит с кластером и его производительностью при регулировании настроек выделения ресурсов для виртуальных машин. Утилита позволяет получить рекомендации относительно того, как можно изменить настройки ресурсов ВМ для достижения оптимальной производительности.
DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:
Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000
Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz
Для того, чтобы начать пользоваться DRMdiagnose, нужно скопировать в рабочую папку с утилитой снапшот кластера (drmdump), содержащий информацию о виртуальных машинах и их запросы на вычислительные ресурсы. Находится он вот тут:
vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
Сама утилитка может работать в трех режимах:
Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).
Выглядят снапшоты кластера вот так:
А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:
Формат использования DRMdiagnose:
Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.
Иногда бывает так, что VMware ESXi может начать вести себя странно, но симптомы могут быть совершенно разными, например:
Не работает vMotion - отваливается на 13% с ошибкой "A general system error occurred: Timed out waiting for vpxa to start" или зависает вовсе
Не работает консоль виртуальной машины (Unable to contact the MKS)
Не зайти на хост VMware ESXi по SSH
Хост ругается на отсутствие свободного места, хотя оно есть на разделах ESXi (No free space left on device)
и прочие неприятности
При этом иногда сходу и не скажешь, что произошло. А проблема вот в чем: у файловых систем ОС Unix есть объекты inode - структуры данных, где хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени. Так вот, этих inode - ограниченное количество, и при большом количестве файлов они могут просто закончиться.
Чтобы проверить количество доступных inodes надо выполнить следующую команду на VMware ESXi (подробнее в KB 1007638):
Вот тут мы видим, что из 640 тысяч айнодов свободно 580 тысяч, то есть все в порядке.
Откуда может взяться так много файлов? Оказывается это случается, когда включен демон SNMPD на VMware ESXi 5.1. Каталог /var/spool/snmp начинает быстро засираться файлами SNMP-трапов. Если у вас включен SNMP и в этом каталоге более 2000 файлов - вероятность возникновения описанного выше поведения высока.
Выход - почистить папку и сделать так, как написано в статье KB 2040707.
Если вы заглянете в папку с работающей виртуальной машиной в VMware ESXi 5.1 из консоли, то увидите, что там находятся 2 конфигурационных файла VMX:
Не стоит думать, что файл vmx~ - это lock-файл вроде тех, которые бывают для виртуальных дисков VMDK (lck). На самом деле, это так называемый "edit file", который нужен для того, чтобы вносимые в конфигурацию виртуальной машины изменения сначала сохранялись в нем, а затем эти два файла меняются местами.
Таким образом, этот файл вам пригодится, если оригинальный vmx-файл будет поврежден или потерян, так как vmx~ является точной копией его последнего рабочего состояния.
Поэтому не стоить вносить правки в файлы vmx вручную, а стоит воспользоваться интерфейсом vSphere Client:
Можно также внести правки в расширенные настройки виртуальной машины через интерфейсы удаленного администрирования, например, как описано в этой статье.
Таги: VMware, vSphere, VMachines, ESXi, Blogs, Обучение
Если заглянуть в секцию Network утилиты esxtop, то там (начиная с ESXi 5.1) можно увидеть объекты Shadow of vmnic1 и т.п.:
На самом деле, эти штуки созданы для обеспечения работы функций VDS Network Health Check, которые появились в VMware vSphere 5.1. Для каждого физического интерфейса создается shadow port, через который посылаются пакеты Health Check, связанные с состоянием этого порта. Эти виртуальные интерфейсы можно мониторить на предмет работоспособности означенной функциональности.
Если эти штуки вам мешают, то можно убрать их, отключив модули хоста ESXi, связанные с хэлсчеком (заодно и в целях безопасности). Для этого нужно выполнить следующую последовательность команд для выгрузки ненужных модулей:
Помните, что после перезагрузки эти изменения не сохранятся - модули снова будут загружены автоматически.
Кстати, не по теме, но хозяйке на заметку: если вы видите, что в esxtop какой-либо счетчик принимает только значения 0 или 100 - знайте, что это просто означает работает эта штука в данный момент времени или нет. Так, например, происходит с SIOC. Просто нет еще в esxtop булевых метрик.
Как многие помнят, ранее в настройках VMware Tools можно было настраивать синхронизацию времени гостевой ОС со временем хост-сервера VMware ESXi. Доступно это было при двойном клике на иконку VMware Tools в гостевой системе:
Теперь же, начиная с vSphere 5.1, при двойном клике на иконку VMware Tools вы увидите следующее:
То есть тут, по-сути, доступна только информация о версии пакета. Это правильно, так как пользователю виртуальной машины не должно быть доступно никаких действий и настроек, относящихся к слою виртуализации.
Вместо этого, различные настройки, в том числе синхронизации времени, были вынесены в категорию VMware Tools опций виртуальной машины (Virtual Machine –> Edit Settings –> Options –> VMware Tools):
Теперь администраторам VMware vSphere не требуется полномочий в гостевой ОС, чтобы регулировать настройки VMware Tools.
Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.
Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:
provisioning.relocate.enableRename со значением true
Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...
Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?
Оказывается, один из самых частых вопросов по продукту для виртуализации настольных ПК VMware View - это как можно показать PCoIP-сессию пользователя через средство управления vSphere Client (по умолчанию там показывается чистый экран).
Для этого необходимо поменять настройку в шаблоне групповой политики (GPO) pcoip.adm. Находится этот шаблон на View Connection Server в папке:
Нужно запустить Group Policy Management, затем создать или привязать к организационной единице AD пула виртуальных ПК групповую политику. В контекстном меню данной групповой политики выбрать пункт "Edit…". В появившемся окне "Group Policy Management Editor" в контекстном меню пункта "Computer Configuration –> Policies –> Administrative Templates" выбрать пункт "Add/Remove Templates…". В появившемся окне "Add/Remove Templates" нажать на кнопку "Add.." и выбрать файл с ADM-шаблоном "pcoip.adm".
Далее нужно установить Enable для настройки "Enable access to PCoIP session from a vSphere console":
Затем нужно применить политики и презагрузить десктоп VMware View. После этого в vSphere Client в консоли виртуальной машины вы будете наблюдать то же самое, что и для VMware View Client:
Более подробно о настройках шаблона pcoip.adm можно узнать из документации.
В этой части статьи разберем рекомендации по настройке взаимодействия физических клиентских устройств и виртуальных десктопов. С точки зрения информационной безопасности это важные ограничения, т.к. влияет явно на возможную передачу конфиденциальной информации между физическими клиентскими устройствами и виртуальными десктопами. Глобально пользователи должны использовать виртуальные десктопы в удаленном режиме (Remote Mode, Online). Т.е. физически виртуальные десктопы должны находиться на серверах, а не клиентских устройствах пользователей...
Начиная с версии VMware vSphere 4.0, компания VMware сделала замечательную вещь - все выпускаемые ей в комплекте с платформой виртуализации пакеты VMware Tools обратно совместимы со всеми прошлыми версиями хостов VMware ESXi:
Соответственно, на VMware ESX 4.0 можно использовать VMware Tools от vSphere 5.1, но как сделать это, не обновляя платформу виртуализации? Оказывается есть простой метод, опубликованный на v-front.de и основанный на информации из KB 2004018.
Там будет один или два файла с расширением .vib. Если их два, то тот, что с меньшим номером билда - это тулзы, содержащие только обновления безопасности, а тот, что с большим - включает и эти обновления, и багофиксы. Берем тот, что с большим номером (609), кликаем на нем 2 раза и проваливаемся дальше в архив, где виден репозиторий VMware Tools:
Эти три папки вы уже когда-то видели на Datastore в ESXi (во время установки тулзов). Создаем папку с именем vmware-tools на локальном хранилище ESX / ESXi и заливаем туда три извлеченные из vib'а папки, чтобы получилось вот так:
Теперь нужно настроить хост ESXi для использования данного репозитория VMware Tools. Для этого идем в Advanced Settings хоста ESXi и настраиваем параметр UserVars.ProductLockerLocation, где прописана версия тулзов в формате:
/locker/packages/<ESXi-Version> (ESXi-Version = 5.1.0, 5.0.0, 4.1.0 or 4.0.0)
В нашем случае она выглядит так:
/locker/packages/5.1.0
Меняем ее на путь к репозиторию: /vmfs/volumes/<имя Datastore>/vmware-tools.
После этого нужно перезагрузить хост, и изменения вступят в силу. Если перезагружать ESXi не хочется, то можно в корне файловой системы пересоздать символьную ссылку /productLocker:
Можно также вызвать команды, которые вызываются хостом для пересоздания символьных ссылок:
/sbin/configLocker - для ESX / ESXi 4.x
jumpstart --plugin=libconfigure-locker.so - для ESXi 5.x
Теперь остается только выбрать пункт Install/Upgrade VMware Tools в консоли vSphere Client при подключении к консоли ВМ для обновления компонентов пакета.
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
Рост бизнеса компании ИТ-ГРАД по предоставлению в аренду виртуальных машин на платформе VMware vSphere в столице и, как следствие, рост числа сотрудников повлекли за собой необходимость поиска нового, более просторного помещения. Новый офис находится в бизнес-центр «Золотое кольцо», в минуте ходьбы от ст. м.Кожуховская. Телефон остался прежним: +7 (495) 748-05-77.
Точный адрес можно посмотреть в разделе "контакты". Мы всегда рады видеть Вас у нас в гостях! Также в связи с расширением у нас открыты вакансии в Москве.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Для получения информации об исправлении ошибки можно подписаться на KB 2042164.
Известный многим Duncan Epping в своем блоге рассказал об изменениях, которые произошли в механизме обнаружения события изоляции хост-сервера ESXi в VMware vSphere 5.1. Приведем их вкратце.
Как мы уже писали вот тут, кластер VMware HA следующим образом обрабатывает событие изоляции (отсутствие коммуникации с другими серверами кластера):
T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и инициирует действие, указанное в isolation response
В VMware vSphere 5.1 появилось небольшое изменение, выражающееся в том, что хост ждет еще 30 секунд после объявления себя изолированным до инициации действия isolation response. Это время можно отрегулировать в следующей расширенной настройке кластера:
das.config.fdm.isolationPolicyDelaySec.
Таким образом, теперь последовательность выглядит так:
T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и
T+60 сек - хост инициирует действие, указанное в isolation response
Наглядно:
Данные изменения были сделаны, чтобы обрабатывать сценарии, где не действие isolation response при наступлении изоляции хоста нужно обрабатывать через длительное время или не обрабатывать совсем.
Зачастую администраторам VMware vSphere требуется снять скриншот консоли виртуальной машины, который появляется вследствие различных ошибок или при установке ОС в ВМ. Делают они это, как правило, нажимая принтскрин в ОС, где установлен vSphere Client. Однако этот способ не очень красивый и не особо универсальный - ниже мы покажем, как правильно делать скриншот консоли ВМ.
Для этой операции мы снова задействуем MOB (Managed Object Browser), о котором мы уже писали тут и тут. Сначала нам надо получить MoRef ID виртуальной машины на определенном хосте VMware ESXi. Вкратце: MoRef ID присваивается виртуальной машине (и другим объектам) сервером vCenter для различных операций с ней, в том числе через MOB (он также используется в vCloud Director и других продуктах). MoRef ID уникален в пределах одного сервера vCenter.
Для получения MoRef ID воспользуйтесь статьей KB 1017126 - в ней все понятно расписано по шагам. Можно также воспользоваться скриптом vSphere MoRef ID Finder, который написал Вильям Лам.
Далее в адресной строке браузера наберите:
https://<IP хоста ESXi>/screen?id=vm-171
где vm-171 - это MoRef ID виртуальной машины. После авторизации пользователя (у которого должна быть привилегия VirtualMachine.Interact.ConsoleInteract) скриншот консоли ВМ будет выведен прямо в браузер.
При получении скриншота ВМ можно использовать еще несколько GET-параметров:
w = ширина получаемой картинки h = высота получаемой картинки x0 = координата X левого угла для снятия скриншота региона y0 = координата Y левого угла для снятия скриншота региона x1 = координата X правого угла для снятия скриншота региона y1 = координата Y правого угла для снятия скриншота региона
Примеры отработки MOB для получения скриншотов ВМ с различными параметрами:
Отличный пост про симулятор сервера vCenter написал William Lam. Изложим здесь его вкратце. Когда-то два человека, Zhelong Pan и Kinshuk Govil, написали утилиту vcsim, которая позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance). Утилита входит в состав vCSA, но отсутствует в обычной инсталляции vCenter.
Помимо собственно построения виртуального Inventory сервера vCenter из виртуальных машин и хост-серверов, утилита vcsim поддерживает простейшие операции с фейковыми объектами, например, Power On ненастоящих машин, а также различные метрики производительности. Кроме того, с помощью этой утилиты можно и добавлять настоящие серверы VMware ESXi и виртуальные машины, создавая гибридную конфигурацию, так как vcsim - это, все же, настоящий vCenter Server.
Теперь приведем ситуации, когда такая конфигурация может оказаться полезной:
При изучении vSphere API для исследования функций навигации по иерархии.
Возможность создать "виртуальное" окружение для тестирования различных скриптов.
Разработка утилит, отслеживающих производительность
Разработка плагинов к vSphere Web Client
Для начала работы с vcsim нужно внести изменения в файл /etc/vmware-vpx/vpxd.cfg, поместив туда следующее между тэгами </vpxd> и </config>:
Кстати, шаблон конфигурации vcsim представлен в файле:
/etc/vmware-vpx/vcsim/model/vcsim.cfg.template
После этого нужно перезапустить сервис vCenter:
service vmware-vpxd restart
Такой перзапуск сервиса можно делать только один раз (даже если он был не успешен), дальше будут использоваться другие команды, приведенные ниже.
После рестарта сервиса мы можем увидеть окружение с сотнями хост-серверов и десятью тысячами виртуальных машин, как в веб-клиенте:
\
так и в "толстом" клиенте:
Теперь мы можем менять параметры окружения в файле:
/etc/vmware-vpx/vcsim/model/initInventory.cfg
В нем можно настраивать следующие объекты:
Datacenter
Hosts per Datacenter
VM per Host
Powered On VM per Host
Cluster per Datacenter
Host Per Cluster
Resource Pool per Cluster
VM per Resource Pool
Powered On VM
vCPU for a VM
vMEM for a VM
После того, как вы сохранили внесенные в конфигурацию изменения, нужно выполнить команду vpxd -b, чтобы пересоздать базу симулируемого vCenter. Поэтому выполняем следующую последовательность для рестарта сервиса:
service vmware-vpxd stop vpxd -b
service vmware-vpxd start
Кроме того, vcsim использует следующие конфигурационные файлы:
vcsim/model/metricMetadata.cfg (симулируемые Performance Metrics - по умолчанию их нет)
vcsim/model/vcModules.cfg (симулируемые модули vCenter, например, DRS)
vcsim/model/OperationDelay.cfg (задержки выполнения операций)
Так что теперь можно испытывать эту штуку и экспериментировать в свободное время. Ну и, само собой, все это никак не поддерживается со стороны VMware.
Таги: VMware, vCenter, vcsim, Blogs, ESXi, VMachines, Обучение
В конце декабря модно давать прогнозы, касающиеся развития технологий в следующем году. Сфера облачных вычислений и технологий виртуализации - не исключение. В этом посте мы постарались собрать наиболее значимые прогнозы, которые в последнее время появились на страницах различных изданий и блогов.
Итак:
Прогноз от Savvis - в 2013 году облака будут все еще on-premise, т.е. работать в пределах инфраструктуры компании. Выиграют те сервис-провайдеры, которые смогут предоставлять гибридную модель онпремизно-офпремизных услуг. Об этом же говорит и прогноз BlueStripe - крупные компании, само собой, от частного облака в публичное никогда полностью не уйдут - критичные сервисы всегда будут в своем датацентре:
Прогноз от Veeam Software - гипервизоры VMware и Microsoft будут сосуществовать в инфраструктурах компаний, а также средний и малый бизнес будет использовать возможности виртуализции, которые традиционно считались доступными только Enteprise-сектору.
В том же прогнозе рассказано про HPC Cloud Computig - высокопроизводительные публичные облака. На эту тему, конечно же, мы вспомним нашу заметку "Еще одно публичное облако IaaS - Google Compute Engine". И дествительно, кому как не Гуглу таким заниматься? Но надо помнить, что на этом рынке есть еще Microsoft (вот тут) и, конечно же, первопроходец облачных сервисов - Amazon (вот тут).
Прогноз от Citrix - концепция BYOD будет мейнстримом. Такой прогноз от Citrix неудивителен, поскольку компания предоставляет средства создания инфраструктуры доступа к корпоративным приложениям с любого устройства, которое захотел пользователь. Интересно также мнение Citrix о том, что Windows-приложения уже не будут рулить как раньше - это очевидно, поскольку все мы знаем, кто захватил мобильные платформы.
Также еще несколько предсказаний вы можете почитать вот тут. Ну и интереснейшая серия прогнозов на 2013 год вот тут (я выбрал самые интересные):
В данной части рассмотрим рекомендации к настройке виртуальных десктопов, как собственно виртуальных машин и их параметров, так и их гостевой операционной системы. Рекомендуется виртуальному десктопу назначать только одну сетевую карту (сетевой адаптер). Во-первых, в большинстве случаев пользователю просто не нужно две сетевые карты, а, во-вторых, сетевые карты естественно будут подключены к разным сетям и могут "шунтировать" межсетевой экран и маршрутизировать пакеты между этими сетями бесконтрольно... Таги: VMware, View, Security, Blogs, Enterprise, VDI
Как вы знаете, в VMware vSphere можно получить информацию о текущих лицензиях для хостов ESXi и vCenter как через "толстый" vSphere Client, так и через "тонкий" vSphere Web Client:
Иногда эту информацию хочется получить через API, например, чтобы иметь всегда актуальный отчет о лицензировании или в целях инвентаризации ключей. Для этого в иерархии объектов vSphere есть объект LicenseManager, который имеет методы для добавления, удаления и просмотра лицензий на хостах VMware vCenter / ESXi.
Для просмотра всех доступных лицензий в системе используется свойство licenses, которое содержит весьма подробную информацию о лицензиях, включая, собственно, сами лицензионные ключи и лицензированные фичи. Есть также свойства expirationDate, expirationMinutes и expirationHours, позволяющие узнать, когда лицензии закончатся.
Известный многим William Lam написал скрипт getLicenseInfo.pl, который использует LicenseManager для получения нужной информации о лицензировании (туда включена также информация не только о vSphere, но и о других продуктах семейства vCenter):
Скрипт может быть использован как для отдельных хостов ESXi, так и для централизованного сбора ключей через vCenter. Для отображения лицензионных ключей открытым текстом нужно вызывать скрипт с параметром –hide_keyfalse.
Давно мы что-то не писали про сравнения платформ виртуализации, которые, зачастую, сильно попахивают предвзятостью и переворачиванием фактов. Но на этот раз мы бы хотели отметить одно из немногих достаточно независимых сравнений "Enterprise Hypervisor Comparison", в котором автор сам явно указывает, что идеального продукта для любой инфраструктуры нет. Особенно если брать в расчет стоимость решения.
В документе рассмотрены следующие платформы виртуализации в различных аспектах функциональности, необходимой для среднего и крупного предприятия:
VMware vSphere 5.1
Microsoft Windows/Hyper-V Server 2012
Red Hat Enterprise Virtualization 3.1 (на данный момент в стадии беты)
Для Windows Server 2012 и Hyper-V данные приведены с учетом Microsoft System Center 2012
Service Pack 1, который еще не выпущен, о чем в документе сделана специальная пометка. Надо отметить, что автор рассматривал только полнофункциональные версии продуктов и не рассматривал их бесплатные версии.
В целом, получилось неплохое сравнение, которое, однако, нельзя рассматривать как единственный источник информации при выборе решения.
Таги: VMware, Microsoft, Red Hat, Сравнение, vSphere, RHEV, Hyper-V, Blogs, Enterprise
Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).
Это новое пространство имен выглядит вот так:
esxcli storage san
Например, мы хотим сделать Reset для FC-адаптера:
esxcli storage san fc reset -A vmhba3
А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:
esxcli storage san fc events get
Можно собрать статистику по iscsi-адаптеру командой:
esxcli storage san iscsi stats get
Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.
Посмотреть статистики SSD-дисков можно командой:
esxcli storage core device smart get -d naa.xxxxxx
Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.
Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.
Для осуществления делегирования административных задач пулы виртуальных десктопов отдельных клиентов, которым предоставляется услуга (возможно филиалов, других предприятий и т.п.) следует располагать в своей выделенной папке (folder) иерархии VMware View Manager. Пулы виртуальных десктопов различных типов также рекомендуется располагать в отдельных папках (folder) иерархии VMware View Manager... Таги: VMware, View, Security, Blogs, Enterprise, vSphere, VDI
Если вам требуется удобный поиск и навигация по большим созданным профилям хостов, созданным с помощью функций VMware vSphere Host Profiles, то можно сделать их экспорт в формат VPF (VMware Profile Format):
Затем в получившемся файле поменять расширение с *.vpf на *.xml и открыть его в своем любимом просмотрщике XML:
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.
8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
Не так давно мы писали о политиках ценообразования для облачной IaaS-платформы Microsoft Azure, которая позволяет брать виртуальные машины с Microsoft Windows или Linux в аренду для организаций (сейчас находится в стадии Preview - что-то вроде бета-версии). Как известно, у Microsoft под цели Azure выделено несколько датацентров (каждый из которых дублирован в соответствующем регионе):
US North Central – Chicago, IL
US South Central – San Antonio, TX
West Europe – Amsterdam
North Europe – Dublin
East Asia – Hong Kong
South-East Asia – Singapore
Есть даже интересное видео про то, как эти датацентры устроены, и как они работают:
На их строительство и ввод в эксплуатацию было затрачено аж 2,5 миллиарда грина. Скоро будет построено еще 13 датацентров, что намекает на то, что Microsoft серьезно рассчитывает получить немалую прибыль с облачного бизнеса.
Однако тут обнаруживаются интересные вещи, касающиеся доступности IaaS-сервисов Azure. На конференции Microsoft TechEd, проходившей в июне 2012 года, были показаны следующие показатели доступности в рамках SLA для пользователей Microsoft Azure:
Как мы видим, для одиночных ВМ гарантируемый показатель доступности на 0,05 ниже, чем для тех приложений, ВМ которых дублированы (а доступ осуществляется, например, через балансировщик). Это ок.
А вот, что было показано уже в октябре 2012 года на конференции Build (пруф на 36-й минуте этого видео):
Куда делся SLA для виртуальной машины, архитектура приложения в которой не подразумевает дублирование на уровне нескольких экземпляров ВМ? Его просто нет. SLA исчез. Это значит, что такая машина Azure может простаивать не 8,75 часов в год, а все 875 часов, и Microsoft ничего за это не будет. Вот такие вот "облака" у Microsoft.
В некоторых наших статьях мы уже затрагивали приемы работы с утилитой vsish (VMkernel Sys Info Shell), которая есть в консоли хостов VMware ESXi, и которая предназначена для управления огромным числом обычных и скрытых настроек сервера и ядра VMkernel (то, что раньше управлялось с помощью команды esxcfg-advcfg). Например, мы уже писали про то, как с помощью vsish можно:
Однако, как вы уже догадались, эти три примера не являются исчерпывающими вариантами использования утилиты vsish. Напомним, что работать с ней нужно в следующем формате:
Запускаем утилиту:
~ # vsish
Далее узнаем значение параметра или настройки:
/> get <параметр, путь к файлу>
Устанавливаем новое значение:
/> set <параметр, путь к файлу> <значение>
Можно выполнить команду сразу, с опцией -e. Например:
~ # vsish -e get /power/hardwareSupport
Большинство параметров утилиты vsish, содержащие путь /config - это расширенные настройки хоста ESXi, которые вы можете редактировать в Advanced Settings через vSphere Client или vSphere Web Client. Вот, например, мы недавно писали о том, как административные привилегии на ESXi назначить пользователю из Active Directory:
Для этой настройки есть соответствующий путь для vsish. Выглядит он так:
/config/HostAgent/plugins/hostsvc/esxAdminsGroup
Однако vsish позволяет редактировать и скрытые настройки ESXi, которые недоступны для изменения через GUI. Полный список настроек vsish для хостов VMware ESXi 4.1 и выше приведен у Вильяма Лама:
Автор сайта v-front.de выпустил обновленную версию утилит ESXi5 Community Packaging Tools 2.0 (ESXi5-CPT), которые позволяют создавать пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). Для VIB-файлов их статус (acceptance level) будет указан как Community Supported. Об этих утилитах от Andreas Peetz мы уже писали вот тут. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.
Новые возможности ESXi5 Community Packaging Tools 2.0:
Поддержка VMware ESXi 5.1.
Обновленный TGZ2VIB5.cmd 2.0:
Добавлены новые опции GUI с дополнительными настройками VIB и параметрами установки
Добавлено меню для загрузки шаблонов настроек для различных типов пакетов (например, "Hardware driver" или "Firewall rule")
Возможность не указывать контрольные суммы в дескрипторном XML-файле
Утилита VIB2ZIP не изменялась.
Скачать ESXi5 Community Packaging Tools 2.0 можно по этой ссылке.
Также, напомним, что на сайте проекта VMware Labs есть еще одно средство для создания VIB-пакетов для VMware ESXi, но работающее только в командной строке и под Linux - VIB Author.
Одна из дополнительных опций VIB Author - это возможность задания электронной подписи к VIB-файлу, однако это не требуется для пакетов уровня Community Supported. Кроме того, VIB Author позволяет редактировать далеко не все директории, поэтому ESXi5-CPT - наш выбор.
Данная статья посвящена аспектам защиты инфраструктуры виртуальных десктопов, построенной на базе программного обеспечения VMware View. На текущий момент у VMware отсутствуют рекомендации по обеспечению защиты инфраструктуры VMware View наподобие Hardening Guide для VMware vSphere. Точнее сказать они есть, но разрозненны и находятся в различных документах. В части 1 статьи попытаемся рассмотреть рекомендации, которые могут предъявляться к сетевой архитектуре инфраструктуры виртуальных ПК.
Как мы уже писали, в VMware vSphere 5.1 появилось множество новых возможностей, в том числе улучшения, касающиеся аппаратной виртуализации (Hardware Virtualization), которая позволяет запускать вложенные гипервизоры (Hyper-V и ESXi) и виртуальные машины в них. Про то, как это работает в VMware vSphere 5.0, мы уже детально писали вот тут.
В интерфейсе веб-клиента VMware vSphere 5.1 поддержка аппаратной виртуализации включается в настройках виртуальной машины:
Настройки, которые были действительны для ESXi 5.0 - теперь не работают. Все теперь включается только через эту галочку.
Напомним, что в ESXi 5.0 можно было запускать вложенные (Nested) 32-битные и 64-битные виртуальные машины в гипервизорах, которые сами работают в виртуальных машинах. При этом требовалось только наличие поддержки аппаратной виртуализации в процессорах - Intel VT или AMD-V. Если же в вашем процессоре не было поддержки Intel EPT или AMD RVI, то вложенные 64-битные машины работали очень и очень медленно.
Поэтому VMware в vSphere 5.1 решила изменить концепцию, сделав так:
Если в процессоре есть поддержка Intel VT или AMD-V без EPT/RVI, то вы сможете устанавливать ESXi 5.1 в виртуальной машине, а также использовать вложенные 32-битные виртуальные машины. При этом 64-битные работать не будут, а опция "Hardware Virtualization" в vSphere Web Client будет загреена. Во время установки ESXi в виртуальной машине вы увидите сообщение "No Hardware Virtualization Support", которое можно просто игнорировать.
Если в процессоре есть поддержка аппаратной виртуализации и EPT/RVI, то можно использовать вложенные 64-битные ВМ.
Проверить свой хост-сервер на наличие поддержки технологий аппаратной виртуализации можно на соответствующих ресурсах вендоров (например, ark.intel.com). Есть и способ попроще - для этого надо использовать Managed Object Browser. Зайдите на хост ESXi по адресу:
Там будет такое свойство nestedHVSupported, которое будет установлено в True, если процессор поддерживает полный набор техник аппаратной виртуализации, который необходим для запуска вложенных 64-битных виртуальных машин на виртуальном ESXi 5.1.
Достаточно давно, известный многим Duncan Epping писал о стартапе CloudPhysics, для которого он является техническим эдвайзором, и который выпускает продукт в виде виртуального модуля (Observer Virtual Appliance), систематизирующий информацию о количественных параметрах виртуальной среды VMware vSphere в виде карточек. На основе этих карточек можно составить заключение о существующих проблемах своей инфраструктуры виртуализации:
Для работы продукта потребуется установить OVA-модуль в своем окружении VMware vSphere, а дальше для просмотра параметров карточек можно использовать веб-консоль (для кого-то это может быть проблемой, так как данные посылаются на сервер CloudPhysics, однако они утверждают, что данные полностью обезличены).
Сами карточки формируются на базе опросов пользователей и всяческих голосований, которые проводятся, например, на конференциях VMworld. Вот примеры таких карточек:
Затем лучшие карточки, будучи реализованными технически, попадают в основной интерфейс продукта (при этом для появления новых карточек не обязательно обновлять виртуальный модуль в своей инсталляции).
Помимо этого есть всякие технические детали о виртуальной инфраструктуре, корелляции параметров и необычные метрики. В общем, для больших инсталляций в плане траблшутинга - штука интересная, попробуйте, это пока бесплатно.
RSS
\
